Application programs typically require input from a user. This user input is entered through an input/output ("I/O") device, such as a keyboard or a mouse. An operating system provides the interface between application programs and the components of a computer system, including I/O devices. The operating system receives the user input and then distributes the user input to the application program to which it is directed.
Many operating systems support multitasking. A task is a stand-alone application program or a subprogram that is run as an independent entity. Multitasking is the ability of a computer system to have more than one task in memory at a time and to switch which task the central processing unit ("CPU") is currently executing to improve the efficiency of the computer system's components. With a multitasking operating system, the receipt of user input must be coordinated among all the tasks that are in the process of executing.
One model for coordinating the receipt and distribution of user input is the synchronous input model. Under the synchronous input model, all user input is stored in a system input queue, and the task that has control of the CPU is the only task that can retrieve input from the system input queue. The primary disadvantage of a synchronous input model is if the task that has control of the CPU stops retrieving input from the system input queue for some reason, all other tasks are blocked from retrieving input from the system input queue. Thus, one malfunctioning task affects the entire system.
To eliminate the problems associated with a synchronous input model, an asynchronous input model was developed. Under the asynchronous input model, all user input is only initially stored in a system input queue. The operating system then reads the input from the system input queue, determines to which task the input is directed, and stores the input in a task input queue corresponding to that task. When a particular task has control of the CPU, the task can retrieve input from its own input queue. If one task stops retrieving input from its input queue, the other tasks can still retrieve input from their input queues. Thus, one malfunctioning task cannot affect the entire system.
In some asynchronous input models, the component of the operating system responsible for distributing input from the system input queue to the appropriate task input queue is a system thread. When the system thread is not distributing input, the system thread remains inactive in the background. Then, when input is received and stored in the system input queue, the system thread is scheduled to execute and a context switch is performed to switch from the context of the currently executing thread (such as a thread created to execute an application program) to the context of the system thread. A scheduler is responsible for scheduling all of the threads, including the system thread. In order to perform the context switch, the scheduler: (1) suspends the execution of the currently executing thread, (2) saves the context (i.e., the machine state--registers, stacks, etc.) of the suspended thread, (3) restores the context of the system thread (which has been waiting in the background), and (4) begins the execution of the system thread. Because each of these steps must be performed for every context switch, context switches are computationally expensive and time consuming. Thus, it would be desirable to reduce the number of context switches that must be performed in order to distribute the input stored in the system input queue.